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Related Inventions 

The present invention is related to U. S. Patent (serial number 09/ ), 

which is titled "Dynamic, Real-Time Integration of Software Resources through Services of a 

Content Framework", and U. S. Patent (serial number 09/ ), which is titled 

"Programmatic Management of Software Resources in a Content Framework Environment", 
both of which are commonly assigned to International Business Machines Corporation and 
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which were filed concurrently herewith. 



Field of the Invention 

The present invention relates to computer software, and deals more particularly with 
techniques for building distributed software services as aggregations of other services. 

Description of the Related Art 

The popularity of distributed computing networks and network computing has increased 
tremendously in recent years, due in large part to growing business and consumer use of the 
public Internet and the subset thereof known as the "World Wide Web" (or simply "Web"). 
Other types of distributed computing networks, such as corporate intranets and extranets, are also 
increasingly popular. As solutions providers focus on delivering improved Web-based 
computing, many of the solutions which are developed are adaptable to other distributed 
computing environments. Thus, references herein to the Internet and Web are for purposes of 
illustration and not of limitation. 

The early Internet served primarily as a distributed file system in which users could 
request delivery of already-generated static documents. In recent years, the trend has been to add 
more and more dynamic and personalized aspects into the content that is served to requesters. 
One area where this trend is evident is in the increasing popularity of content frameworks such as 
those commonly referred to as "portals" (or, equivalently, portal platforms, portal systems, or 
portal servers). A portal is a type of content framework which is designed to serve as a gateway, 
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or focal point, for end users to access an aggregation or collection of information and 
applications from many different sources. Portals are typically visual in nature, and provide their 
users with a Web page known as a "portal page", A portal page is often structured as a single 
overview-style page (which may provide links for the user to navigate to more detailed 
information). Alternatively, portal pages may be designed using a notebook paradigm whereby 
multiple pages are available to the user upon selecting a tab for that page. Some experts predict 
that portal pages will become the computing "desktop" view of the future. 

Another area where advances are being made regarding dynamic content is in the so- 
called u web services" initiative. This initiative is also commonly referred to as the "service- 
oriented architecture" for distributed computing. Web services are a rapidly emerging 
technology for distributed application integration in the Internet. In general, a "web service" is 
an interface that describes a collection of network-accessible operations. Web services fulfill a 
specific task or a set of tasks. They may work with one or more other web services in an 
interoperable manner to carry out their part of a complex workflow or a business transaction. For 
example, completing a complex purchase order transaction may require automated interaction 
between an order placement service (i.e. order placement software) at the ordering business and 
an order fulfillment service at one or more of its business partners. 

Many industry experts consider the service-oriented web services initiative to be the next 
evolutionary phase of the Internet. With web services, distributed network access to software 
will become widely available for program-to-program operation, without requiring intervention 
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from humans. 

Web services are generally structured using a model in which an enterprise providing 
network-accessible services publishes the services to a network-accessible registry, and other 
enterprises needing services are able to query the registry to learn of the services' availability. 
5 The participants in this computing model are commonly referred to as (1) service providers, (2) 
service requesters, and (3) service brokers. These participants, and the fundamental operations 
involved with exchanging messages between them, are illustrated in Fig. 1. The service 
p providers 100 are the entities having services available, and the registry to which these services 
tfl are published 1 1 0 is maintained by a service broker 120. The service requesters 1 50 are the 
|<jj> entities needing services and querying 140 the service broker's registry. When a desired service 
rg is found using the registry, the service requester binds 130 to the located service provider in 
p order to use the service. These operations are designed to occur programmatically, without 

human intervention, such that a service requester can search for a particular service and make use 
2 of that service dynamically, at run-time. The web services model is theoretically available for 
1 5 any type of computing application. However, the web services which are accessible from 
registries today are limited to relatively simple programs such as "Hello, World!" demo 
programs, programs which look up the current temperature for a particular zip code, programs 
which perform currency exchange calculations, and so forth. 
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The core set of standards on which web services work is being built includes HTTP 
("Hypertext Transfer Protocol"), SOAP ("Simple Object Access Protocol") and/or XML 
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("Extensible Markup Language") Protocol, WSDL ("Web Services Description Language"), and 
UDDI ("Universal Description, Discovery, and Integration"). HTTP is commonly used to 
exchange messages over TCP/IP ("Transmission Control Protocol/Internet Protocol") networks 
such as the Internet. SOAP is an XML-based protocol used to send messages for invoking 
5 methods in a distributed environment. XML Protocol is an evolving specification of the World 
Wide Web Consortium ("W3C") for an application-layer transfer protocol that will enable 
application-to-application messaging, and may converge with SOAP. WSDL is an XML format 
for describing distributed network services. UDDI is an XML-based registry technique with 
f~l which businesses may list their services and with which service requesters may find businesses 
3W providing particular services. (For more information on SOAP, refer to "Simple Object Access 
111 Protocol (SOAP) 1 . 1 , W3C Note 08 May 2000", which is available on the Internet at 
|j http://www.w3.org/TR/2000/NOTE-SOAP-20000508. See http://www.w3.org/2000/xp for more 
f ; information on XML Protocol and the creation of an XML Protocol standard. The WSDL 

specification is titled "Web Services Description Language (WSDL) 1.1, W3C Note 15 March 
B 2001 and may be found on the Internet at http://www.w3.org/TR/2001/NOTE-wsdl-200103 15. 
For more information on UDDI, refer to the UDDI specification which is entitled "UDDI 
Version 2.0 API Specification, UDDI Open Draft Specification 8 June 200 1" and which can be 
found on the Internet at http://www.uddi.org/specification.html. HTTP is described in Request 
For Comments ("RFC") 2616 from the Internet Engineering Task Force, titled "Hypertext 
20 Transfer Protocol -- HTTP/1 . 1 " (June 1 999).) 



Application integration using these open standards requires several steps. The interface 
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to a web service must be described, including the method name(s) with which the service is 
invoked, the input and output parameters and their data types, and so forth. WSDL documents 
provide this information, and are transmitted using a UDDI publish operation to a registry 
implemented according to the UDDI specification. Once the service is registered in the UDDI 
registry, service requesters can issue UDDI find requests to locate distributed services. A service 
requester locating a service in this manner then issues a UDDI bind request, which dynamically 
binds the requester to the located service using the service information from the WSDL 
document. (These UDDI operations have been illustrated, at a high level, in Fig. 1 .) 
SOAP/XML Protocol and HTTP messages are commonly used for transmitting the WSDL 
documents and the UDDI requests. (Hereinafter, references to SOAP should be construed as 
referring equivalently to semantically similar aspects of XML Protocol. Furthermore, it should 
be noted that references herein to "HTTP" are intended in a generic sense to refer to HTTP -like 
functions. Some UDDI operations, for example, require HTTPS instead of HTTP, where HTTPS 
is a security-enhanced version of HTTP. These differences are not pertinent to the present 
invention, however, and thus no distinction is made hereinafter when discussing HTTP.) 

The goal of web services is to provide service requesters with transparent access to 
program components which may reside in one or more remote locations, even though those 
components might run on different operating systems and be written in different programming 
languages than those of the requester. While a significant amount of work has been done to 
define the goals, architecture, and standards on which web services will be based, much work 
remains to be done to make web services operate effectively and efficiently. 
RSW920010189US1 -6- 



SUMMARY OF THE INVENTION 

An object of the present invention is to provide a technique for dynamically integrating 
software resources (including, but not limited to, web services) in a distributed network. 

Another object of the present invention is to provide a technique for leveraging a portal 
5 model and framework for real-time integration of software resources as web services. 

A further object of the present invention is to define techniques for making software 
o resources available for web services using a portlet model. 

7 1 Yet another object of the present invention is to define techniques for using portlets as 

'% web service intermediaries. 

H> Another object of the present invention is to provide a technique for enabling 

^ programmatic management of software resources used in web services. 

A further object of the present invention is to provide a composition model for building 
web services as aggregations of other services and/or software resources. 

Still another object of the present invention is to provide a composition utility which 
1 5 enables fast and efficient construction of web services from other services and/or software 
resources. 
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A further object of the present invention is to leverage a dual aggregation model for web 
services. 

Other objects and advantages of the present invention will be set forth in part in the 
description and in the drawings which follow and, in part, will be obvious from the description or 
may be learned by practice of the invention. 

To achieve the foregoing objects, and in accordance with the purpose of the invention as 
broadly described herein, the present invention provides methods, systems, and computer 
program products for building distributed software services as aggregations of other services. In 
preferred embodiments, this technique comprises: determining a taxonomy of interest for a new 
distributed software service; programmatically scanning a network-accessible registry to locate 
registered services having the taxonomy of interest; determining if each located service has a 
predetermined deployment interface; and providing the located services to a service composition 
tool if the determining step has a positive result. 

The technique may further comprise adding the predetermined deployment interface to 
the located service when the located service does not have the deployment interface, and may 
also or alternatively further comprise determining if each located service has a predetermined 
system interface for managing that located service. The technique may further comprise building 
the new service using selected ones of the provided services. 
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A directed graph representation of the new service may be created, wherein nodes of the 
directed graph represent operations of the new service and edges of the directed graph represent 
transition conditions of the new service, and wherein data mapping operations are associated 
with selected ones of the edges. A markup language document may be created to represent the 
directed graph representation and to register the markup language document in a network- 
accessible registry. 

The new service is preferably modeled as a portlet, as has at least one of (1) a deployment 
interface and (2) a system interface. 

The present invention will now be described with reference to the following drawings, in 
which like reference numbers denote the same element throughout. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 provides a diagram illustrating the participants and fundamental operations of a 
service-oriented architecture, according to the prior art; 

Figure 2 illustrates a sample portal page in which content from visually-oriented portlets 
is rendered, according to the prior art; 



Figure 3 is a block diagram illustrating a portlet structured as a web service proxy, 
according to preferred embodiments of the present invention; 
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Figures 4A and 4B illustrate the content of sample WSDL documents specifying a 
deployment interface and a system interface, respectively, according to preferred embodiments of 
the present invention; 

Figure 5 illustrates a graphical web service composition tool of the type which may be 
created according to the teachings of the present invention; 

Figures 6, 7, 9, 12, 13, and 17 provide flowcharts depicting logic which may be used to 
implement preferred embodiments of the present invention; 

Figure 8 illustrates a web services stack which may be used in a networking environment 
in which the present invention operates; 

Figure 10 provides a sample "tModel" which may be used to publish information to a 
registry; 

Figures 1 1 A - 1 1C are used to illustrate signatures of methods, and the need to provide a 
signature superset when dynamic run-time binding is to be used; 

Figure 14 illustrates a sample "plug link" specification which is representative of those 
used according to the present invention; 
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Figures 15A - 15C provide syntax used to describe mapping of data between operations; 

Figure 16 is a simple example of information that may be contained in a transformation 
registry; and 

Figure 1 8 provides an overview of components used in describing the present invention. 

DESCRIPTION OF PREFERRED EMBODIMENTS 

The promise of web services is that disparate applications will be able to interoperate like 
never before, offering a new breed of seamless hyper-integrated applications through openness 
and urbanization of enterprise systems. Web services will make distributed software resources 
more widely available, and will allow software to be marketed as a service. As web services 
become widespread, there will be a need for managing the services and for an aggregation point 
where these services can be aggregated to form new services which can then be deployed. A 
content framework such as a portal platform provides many built-in services for content 
management and service hosting, such as persistence, personalization, and transcoding. The 
present invention defines novel techniques for leveraging portal platforms, extending the 
platforms to provide for aggregation, deployment, and management of web services. Providing 
access to software services through portal aggregation will lower integration costs and help speed 
time-to-market. This type of portal usage for application-to-application communication may be 
referred to as an "application portal", in contrast to the "visual portals" which are designed to 
display information to human users. Companies providing application portals today promote 
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low-cost Enterprise Application Integration ("EAI") and provide application access and 
management through a standard portal platform. However, existing EAI products do not yet 
programmatically integrate web services nor do they integrate web services in real-time, and 
these existing products require that small "engagements" are manually provided as the "glue" 
necessary to define a static binding to hook web services into a portal before applications can be 
deployed. (For example, an engagement may be needed to surface the interface to an enterprise's 
customer relationship management, or "CRM", software resources at the visual portal. The 
engagements often use proprietary software and/or custom-defined XML communications. This 
approach is therefore not suitable for dynamic, programmatic aggregation or integration on a 
global scale.) Current estimates are that creating such engagements requires anywhere from 
several days to several weeks. JamCracker, Onyx, and US Internetworking are among the 
companies providing EAI using application portals today. No systems are known to the 
inventors which enable real-time deployment of software resources by aggregating them in a 
modeling composition tool, and then programmatically integrating and managing them using 
open industry standards as disclosed herein. 

The present invention defines techniques for integrating web services and other back-end 
software resources into an application portal platform using a portlet model or paradigm, thereby 
creating new web services. One commercially-available portal platform on which the present 
invention may be implemented is the WebSphere® Portal Server ("WPS") from the International 
Business Machines Corporation ("IBM"). ("WebSphere" is a registered trademark of IBM,) 
Note, however, that while discussions herein are in terms of a portal platform, the inventive 
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concepts are applicable to other types of content frameworks which provide analogous 
functionality and are also applicable to portals other than WPS, and thus references to portals and 
their portlet paradigm is by way of illustration and not of limitation. Using the disclosed 
techniques, an application portal functions not only as an access point for statically integrating 
5 services after manually providing engagements, as in the prior art, but also functions as a full 
web service utility. In its capacity as a web service utility, a portal platform according to the 
present invention provides programmatic management of web services and dynamic run-time 
integration of web services. 

fk One aspect of the present invention also provides a tool for composition or aggregation of 

M new web services. Using this composition tool, a systems administrator (or, equivalently, a 
w service composer or other person) may define a new service composed of more fine-grained 
% services. According to preferred embodiments of this aspect, the fine-grained services from 
In which other services are built may reside locally or remotely, and the techniques disclosed herein 
enable referencing those services and using those services in a transparent manner without regard 
15 to whether they are local or remote. The fine-grained services may include any form of 

programming logic, including script programs, Java™ classes, COM classes, EJBs ("Enterprise 
JavaBeans"™), stored procedures, IMS or other database transactions, legacy applications, and 
so forth. ("Java" and "Enterprise JavaBeans" are trademarks of Sun Microsystems, Inc.) The 
web services created in this manner can then automatically be managed by the portal platform 
20 and can also be used in creating new web services in a recursive manner, as will be described. 
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The disclosed techniques build on the portal concept of a plug-in, which is referred to in 
the art as a "portlet" Portlets are known in the prior art which are visual in nature. In the visual 
portal model, each portlet is responsible for obtaining a portion of the content that is to be 
rendered as part of the complete portal page for the user. By convention, the portlet' s "service" 
5 method is invoked to return markup language (such as Hypertext Markup Language, or 

"HTML") syntax encapsulating the result of the portlet' s execution. Once the visual portlet' s 
content has been aggregated with other markup language syntax by the portal page from which it 
was invoked, the result is a Web page whose content is well suited for the needs of the portal 
O page's human user. Fig. 2 provides an example of a prior art portal page 200 from a visual 
if portal, where this portal page includes content from three visually-oriented portlets (see elements 
f I 210, 220, 230). Portlet 2 1 0 in this example displays news headlines. Portlet 220 shows a stock 
p ticker for the user's favorite stocks, and portlet 230 displays the current weather and weather 

IS 

p forecast for the user's selected city. 

J"' In many content-rich visual portals, the output of visually-oriented portlets is aggregated 

1 5 physically on the portal page according to the portlets' content categorization or taxonomy. For 
example, output of news feed portlets may be provided on one tabbed page of a notebook-style 
visual portal, with output of weather portlets on another tabbed page and perhaps the output of 
portlets of interest to an enterprise's employees may be provided on another. Or, portlet output 
may be grouped within logical sections of a single portal page. The physical layout of the portal 
20 page may therefore enable end users to find information more quickly and efficiently. Work is 
ongoing to build remote interfaces to visually-oriented portlets such that visual portals can 
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aggregate content from applications which may be located on machines other than the machine 
on which the portal code resides. This aggregated content will then be presented on the portal 
page, and whether it was obtained from a locally-available portlet or from a remote portlet will 
be transparent to the end user. (See, for example, "WebSphere Portal Server and Web Services 
5 Whitepaper", T. Schaeck, published by IBM on the Internet at http://www- 

4 ibmxom/software/solutions/webservices/pdf/WPS.pdf, which discusses remote interfaces to 
visually-oriented portlets.) 

p A portal platform provides a number of services for the portlets it hosts, as described 

tfJ above. The present invention leverages portlets as a portal interface, and also builds upon the 
!g| concept of a remote portlet interface (where this concept is extended as disclosed herein to apply 
fq to programmatic portlets), to enable access to software resources. Portlets functioning according 
0 to the present invention are also referred to herein as "web service intermediaries" or "web 
-f* service proxies", or simply as "intermediaries" or "proxies". That is, a portlet may now act as an 
fv intermediary between an application or software resource requesting a particular service and a 
1 5 software resource providing that service. According to the present invention, the software 

resource performing a particular function may be statically bound to a web service proxy (for 
example, at development time), or a web service proxy may be bound to a software resource 
which is dynamically selected (for example, based upon criteria which are evaluated at run-time). 
In either case, the portlet proxy receives request messages and forwards them to the software 
20 resource to which it is bound; once the software resource has completed the requested function, it 
returns its response to the portlet proxy which then forwards the response to the requester. 
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A block diagram illustrating a portlet structured as a web service proxy is shown in Fig. 
3. As shown therein, portlet proxy 340 includes a deployment interface 31 0, a system interface 
320, and a functional interface 330. The portlet proxy communicates with a portal platform 300 
using these interfaces, acting as an intermediary between the portal platform and the software 
5 resource 350 which carries out the function of interest. Details of each functional interface are 
specific to the web service provided by software resource 350, and do not form part of the 
present invention. The present invention, however, makes the functional interface of the 
software resources available as an interface 330 of the portlet proxy. (Exposing the functional 
p interface using WSDL definitions and SOAP services may be accomplished using a 
tO commercially-available tool such as the IBM Web Services Toolkit, or "WSTK", during the 
Jf ; deployment process.) The deployment interface and system interface will be described in more 
detail below. 

The software resources invoked using the techniques of the present invention are 
m typically designed for program-to-program interaction, but may alternatively be visual in nature. 
1 5 For example, visually-oriented resources may be invoked during execution of a web service 

which operates primarily in a program-to-program manner. The term "programmatic portlet" is 
used herein to refer generally to portlet proxies according to the present invention, whether or not 
the underlying software resource involves visually-oriented code. 



20 



A deployment interface and a system interface are defined for each portlet which serves 
as a web service proxy, according to preferred embodiments of the present invention. (In 
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alternative embodiments, advantages of the present invention may be realized by implementing 
either the deployment interface or the system interface separately, and such implementations are 
within the scope of the present invention. For example, there may be cases in which it may be 
desirable not to implement management services for some web services. In such cases, the 
5 system interface may be omitted; alternatively, a system interface might be provided which has 
no operations or which has operations implemented as empty functions.) These new interfaces 
may also be referred to as the deployment port type and system port type, respectively. A portlet 
according to the present invention thus defines a service provider type that includes the port 
Q types necessary for portal integration of software resources and service interaction and 
Ml management. ("Port types" is a term used in the art to signify the specification of a portlet' s 
Jf ; operations, and "service provider type" is a term used to signify a collection of port types.) 

Q The deployment interface enables a portlet proxy (that is, an aggregated web service 

H 5 which is represented by a portlet proxy) to be used in subsequent web service composition 
: W;I operations, in a recursive manner. For example, the deployment interface of a portlet "A" 
1 5 provides information about portlet A for use as portlet A is aggregated with other portlets to form 
a new web service "Z"; by defining a deployment interface for web service Z, according to the 
present invention, information about web service Z can subsequently be provided as service Z is 
used for composing other new services. 

The system interface is used for run-time management of portlets (that is, of web services 
20 represented by portlet proxies) by the portal platform. Use of the system interface allows the 
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portal platform to perform functions such as logging of events, billing, and other types of 
administrative operations pertaining to execution of the web service. This requires 2-way 
communication between the portal platform and the portlet proxy, and uses novel techniques 
which are disclosed herein. 

Referring now to the sample WSDL documents in Figs. 4A and 4B (representing 
interface definitions), the deployment interface specification and system interface specification, 
respectively, are illustrated. According to preferred embodiments, the deployment and system 
port types are represented as WSDL documents for registration in a registry. As shown at 410 of 
the WSDL document 400 in Fig. 4A 5 the example deployment interface is named "Deployment" 
and includes operations such as "getDisplayName" and u getDisplayIconl6xl6" (see element 
430). These operations may be used, for example, to retrieve a descriptive name of the web 
service and to retrieve a graphic image representing the web service for placement on a palette of 
a web service composition tool (such as that illustrated in Fig. 5). According to the WSDL 
specification, the input and output messages used for communicating with a service are specified 
in "<message>" elements 420, where the parameters used by those messages are defined as 
"<part>" elements. Thus, a message element is defined for each message of each operation 
specified for this port type. (Refer to the WSDL specification for more information about the 
details of a WSDL document.) 

The WSDL document 450 in Fig. 4B defines the system interface, which in the example 
is named "System" (see element 460). A complex data type named "Event" is defined (see 
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element 470), comprising 2 string parameters and a date parameter. This data type may be used, 
for example, when exchanging logging data to be recorded in an auditing log file. A "logEvent" 
operation is defined (see element 490), and in this example is a 1-way operation invoked using a 
"logEventReceive" message (see element 480) which has a parameter of type Event. In addition, 
5 the example defines a "reportUsage" operation which has 2 messages "reportlnput" and 
"reportOutput". 

The deployment port type is used at design time, and allows a new web service to be 
Q composed with a web service composition tool such as that illustrated by Fig. 5. The 
tfi deployment port type contains operations pertinent to the modeling composition process. 
TO Representative examples of operations which may be useful for this purpose include 

fri; 

S u getIconl6xl6" and "getIcon32x32" to retrieve icons (such as 520a, 520b) of different sizes for 
O placement on a portlet palette (illustrated by element 510), "getDisplayName" and 

"getDisplayDescription" to provide textual information for presenting to a service composer 
H (such as that illustrated at 521a and 52 lb), "getAuthorName" to retrieve an identification of the 
1 5 software developer or the service composer, and so forth. 

Turning now to Fig. 6, logic is depicted which may be used for creating a portlet proxy 
for use in a composition tool such as that represented by the sample user interface of Fig. 5. 
Note that while the description of Fig. 6 is presented herein in terms of preparing a WSDL 
document describing the portlet' s operations, this logic also outlines what is required for a 
20 developer creating source code for a software resource. For example, if the software resource 
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will report information through its system interface for quality of service or billing purposes, the 
developer must provide code to gather the appropriate data and return this data when requested; 
the method or methods which perform this function may then be identified as part of the system 
port type of the portlet proxy for the software resource. (See interface 320 of Fig. 3, for example, 
illustrating that the system interface of portlet proxy 340 exposes the management operations of 
software resource 350.) This process comprises first determining the operations that will be 
exposed as the portlet proxy's published functional interface (Block 600). For example, suppose 
a programmatic portlet such as the portlet represented by icon 520a in Fig. 5 provides order 
fulfillment services. The public interface of this portlet might include a method named 
"receivePurchaseOrder" (see element 530), which can be used to invoke operations of the 
underlying software resource. Preferably, a human determines which methods of a software 
resource should be publicly exposed; alternatively, programmatic operations could be used to 
select the methods which comprise the public interface. (For example, programmatic operations 
might be designed to select all public methods for exposing, or perhaps to select only the "getter" 
public methods.) 

Once the public interface is identified, WSDL markup language syntax is 
programmatically created to specify this information. This comprises generating <message> and 
<operation> elements, similar to those illustrated in Figs. 4A and 4B. The composer may be 
asked to supply information for use in this process, such as the port type name, the location of 
the name space information, and so forth. Or, this information or parts thereof may be 
programmatically generated and/or retrieved from a configuration file. 
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Techniques for programmatic generation of markup language syntax (using input 
supplied by a human, as well as programmatically-derived information) are known in the art, and 
a detailed description thereof is not deemed necessary for an understanding of the present 
invention. IBM's WSTK is an example of a commercially-available product which may be used 
to programmatically generate WSDL for an existing software resource. See "The Web services 
(r)evolution: Part 4, Web Services Description Language (WSDL)", G. Glass (Feb. 2001), 
published by IBM on the Internet at http://www- 

106.ibm.com/developerworks/webservices/library/ws-peer4, which presents an example of 
programmatically generating a WSDL document for a simple weather service which has 
"getTemp"and "setTemp" operations. Fig. 4 of this document illustrates asking a composer 
which methods of a class should be used in creating a public interface. It should be noted that 
references herein to using a WSDL syntax generator are merely for purposes of illustration; 
alternatively, a developer might manually create WSDL documents or another type of markup 
language syntax tool might be used for this purpose. 

In addition to specifying the public interface, the portlet's deployment port type 
information must be created (Block 610). An example of the deployment port type is illustrated 
in Fig. 4 A. If the port type information is programmatically generated, for example using 
WSTK, this process comprises parsing the software resource's class definition to locate its 
methods providing the operations of the predefined deployment port type and to identify the 
parameters and parameter types of each method, and then generating <message> and <operation> 
elements, as well as <part> elements and <type> definitions as necessary. The composer may be 
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asked to provide input during this process, as needed, such as populating the parameters for the 
messages of the operations, (For example, to populate the "getDisplayIconl6xl60utput" 
parameter, the composer might specify the Uniform Resource Locator, or "URL", of a particular 
image file,) The portlet' s system port type information is also created (Block 620), in a similar 
manner, resulting in a WSDL document such as that shown in Fig. 4B. (In preferred 
embodiments, the deployment and system interface definitions are placed in separate WSDL 
documents as shown in the examples of Figs. 4A and 4B because they describe different 
behavior.) 

Finally, the portlet proxy for the web service is published to a registry (Block 630), after 
which the portlet proxy is available for use in composing new web services and its services are 
available for invocation (e.g. using a conventional UDDI find and bind). In preferred 
embodiments, documents known in the art as "tModels" are used for publishing a portlet proxy's 
web services information to a registry. (A "tModel", according to the UDDI specification, is 
metadata which describes the specifications and the versions of specifications that were used to 
design published services. "tModel" is a generic term for a service "blueprint", defining the 
conventions to which the registered service conforms. For example, if a registered service 
includes an "HTTP 1.1 tModel", then this service is known to adhere to certain requirements and 
conventions associated with that tModel -- and, by implication, adheres to particular 
requirements in its use of HTTP.) Note that a WSDL port type definition can be a tModel; it can 
also be a partial tModel, which is a tModel in a tModel set. Thus, a single tModel may be used 
to register both the deployment and system interfaces. (Refer to the UDDI specification for more 
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information on tModels and tModel sets.) 

Referring now to Fig. 7, logic is shown which may be used to implement a service 
modeling and deployment process via a web service composition tool. Block 700 indicates that 
the new web service is modeled using portlets as proxies or templates for the service being 
aggregated. That is, a portlet may serve as an intermediary for a web service or for a local 
resource, defining an interface to the operations provided by one or more back-end software 
resources. However, the actual software resource(s) providing that service on the back end might 
not be selected and bound until run-time. The service composer is also able to reuse the 
composed templates and dynamically plug in different service providers for a static 
(development-time) binding. 

The web service composition tool preferably provides a portlet palette for use in this 
modeling operation, where registered portlets for a particular taxonomy or category are presented 
on the palette. The service composer then creates a new web service using the composition tool, 
for example by right-clicking on a web service icon to display its available methods and then 
using drag and drop operations to position selection method invocations as operations for 
carrying out a service. Fig. 9, discussed below, illustrates logic with which information may be 
gathered for use by the web service composition tool, including locating the appropriate web 
services to use when constructing the palette. 



In preferred embodiments, a directed graph is used to model the operations involved in 
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executing the new web service. Selected portlet operations represent the nodes of the graph, and 
the graph edges which link the nodes represent potential transitions from one service operation or 
process to another. These service links can be qualified with one or more transition conditions, 
and also with data mapping information if applicable. The conditions specify under what 
5 conditions the next linked service should be invoked. Often, these conditions will be determined 
using the results of a previous service invocation. Data mapping refers to the ability to link 
operations between portlet port types and transfer data from one operation to another. For 
example, the data mapping information may indicate that the output parameters of one service 
are mapped to the input parameters of another service. 

W Preferred embodiments of the present invention leverage the Web Services Flow 

® Language ("WSFL") for directed graphs. In particular, WSFL's persistent storage techniques 
% and run-time evaluation techniques using directed graphs are added to a web services stack to 
ynj operate upon the graphs created by a service composer. For a detailed discussion of WSFL, refer 
^ to the WSFL specification, which is entitled "Web Services Flow Language (WSFL 1.0)", Prof 
1 5 Dr. F. Leymann (May 2001), available on the Internet from IBM at http://www- 

4ibmxom/software/solutions/webservices/pdfiWSFL.pdf, which is hereby incorporated herein 
by reference as if set forth fully. (Note that the WSFL specification discusses use of directed 
graphs for modeling web services, but does not teach directed graphs in combination with 
services which are provided by programmatic portlet proxies. The WSFL specification defines a 
20 "plug link" mechanism, discussed in more detail below with reference to Block 1380 of Fig. 13, 
which can be used in a proxy model to map interfaces in a simple manner as described herein. 
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This plug link mechanism is used by preferred embodiments of the present invention as the 
persistent definition of integrating portlet proxies to implement web services.) 

A web services stack 800 used in preferred embodiments is illustrated in Fig. 8. Service 
flow support 810 is preferably provided by WSFL, as stated earlier. Service discovery 820 and 
5 service publication 830 are preferably provided using UDDL A WSDL layer 840 supports 
service description documents. SOAP may be used to provide XML-based messaging 850. 
Protocols such as HTTP, File Transfer Protocol ("FTP"), e-mail, message queuing ("MQ"), and 
5 so forth may be used for network support 860. As discussed herein, WSDL is used to define web 
m service port types and to define how to invoke operations of these port types, and WSFL is used 
W to aggregate the web services (and therefore to aggregate their interfaces). At run-time, services 
C5 are found within a registry using the UDDI service discovery process, and bound to using 
y information from their WSDL definitions. The WSFL run-time then uses these (port type) 
Jig definitions to aggregate the services. (Because the signatures of the operations will typically not 
i*a match one-to-one, the WSFL plug link mechanism may be used to map between the operation 
15 interfaces.) 

Referring again to the example composition tool user interface in Fig. 5, the composer 
has selected to begin the new service with a "receive purchase order" operation 530, For 
purposes of illustration, suppose this operation evaluates the items on an incoming purchase 
order to determine whether they are in stock or not. Thus, a transition condition 535 indicates 
20 that if an item is out of stock, the next service to be executed is "place order with supplier" 540, 
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whereas if an item is in stock, transition condition 545 applies and the next service to be executed 
for this item is "add item to invoice" 550. Upon occurrence of some event, such as receiving a 
shipment of new items or perhaps receiving a notification that the item had to be ordered from 
the supplier's supplier, transition condition 555 applies and a service "response from supplier" 
560 is to be executed. Presumably, this service evaluates the supplier's response, and if a 
requested item was determined to be available, transition condition 565 applies and the item will 
be added to an invoice by service 550, whereas if a requested item is not available then transition 
condition 575 applies and the next service to be executed is "add item to backorder" 580. As 
will be obvious, the nodes and conditions illustrated in Fig. 5 are merely for purposes of 
illustration. (Data mapping information has been omitted from the example.) 

Turning now to Fig. 9, the process of obtaining information to present to the service 
composer on the user interface of a composition tool during execution of Block 700 of Fig. 7 
preferably begins at Block 900 by determining the taxonomy of interest. One way in which this 
may be performed is to query the composer. As shown by the example in Fig. 5, the composer 
may have requested portlet proxies pertaining to item ordering services, and therefore palette 510 
includes icons 520a, 520b representing an order fulfillment service and an order payment service. 
Once the taxonomy is known, the registry is programmatically scanned (Block 910) for portlets 
whose tModels indicate support for that taxonomy. The scan also checks for tModels 
representing support for the deployment interface disclosed herein, and optionally the system 
interface disclosed herein. See Fig. 1 0 for an example of a tModel that may be used to indicate 
support for the system service provider type of the present invention. (Optionally, a single 
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tModel may be used to represent both the deployment and system service provider types. Or, a 
tModel similar to the one shown in Fig. 10 may be separately created for the deployment service 
provider type.) Note that the WSDL document in Fig. 4B defines an interface template for 
portlet proxies conforming to the sample tModel in Fig. 10. This correspondence is shown, for 
example, in the service provider type named in the descriptive information at 1010, and in the 
file name wherein the service provider type forms part of the URL at 1020. The 
<overviewURL> element of a tModel functions as a type of import statement to reference a 
WSDL service specification, as is known in the art. This tModel, along with its associated key, 
is published as a technical blueprint for a portlet proxy registered in a UDDI registry. 

Block 920 performs a test to see if any more portlets meeting the current criteria are 
available in the registry. If not, then processing continues at Block 930 where the dynamically- 
gathered information is used in the modeling operation to assemble aggregated services as portlet 
proxies. Discussion of the modeling operation continues below with reference to Block 710 of 
Fig. 7. 

When the test in Block 920 has a positive result, then the processing of Blocks 940 
through 980 is performed to obtain information about the registered portlet proxy which has been 
located. Block 940 obtains the portlet proxy's deployment description, which is preferably 
implemented to provide a description of the web service, and Block 950 obtains its deployment 
author information. Use of this information was previously discussed with reference to Fig. 5. 
For example, it may be used if the composer requests to see the properties of a web service 
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presented on the user interface of the composition tool. 

Block 960 obtains information about the icon to be displayed for this service on the user 
interface of the composition tool. Preferably, this information comprises an address such as a 
URL specifying where an icon image is stored. Block 970 obtains the deployment operations for 
this portlet, in effect determining what the portlet can do. 

Preferably, obtaining the deployment information for the portlet proxy in Blocks 940 
through 970 comprises executing well-known methods of the deployment interface by issuing 
the corresponding message from the service's deployment port type. For example, using the 
deployment port type defined in Fig. 4A, the message "getDisplayIconl6xl6Input" may be 
invoked to obtain the portlet' s 16 by 16 icon, and if the portlet has a 

u getDisplayIcon32x32Input" message, this message can be invoked to obtain the portlet' s 32 by 
32 icon. (Blocks 940 through 970 should be considered as representative of the information that 
may be beneficially retrieved for a portlet proxy; additional or different information may be 
deemed useful in a particular implementation of the present invention.) 

After obtaining the pertinent deployment information about the portlet, a representation 
of the portlet is added to the modeling palette (Block 980), and control returns to Block 920 to 
determine if there are more portlets of interest in the registry. The processing of Block 920 has 
been described above. 
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Returning now to the discussion of Fig. 7, once the composer completes the model of 
service interaction as a directed graph 5 at Block 710 the composer declares a service provider 
port type for the newly-aggregated service. In order to define this public interface, the composer 
may select operations to be exposed, or exported, within port types of the service of the 
composition, thereby identifying the public port type. The composer may select as many 
operations for exporting as necessary, and may also define new operations if desired. (For 
example, the composer might decide to define a new name for an operation, and provide a one- 
to-one mapping for that new name to the old name.) These exposed operations specify the 
means for invoking the new service. For example, with reference to the sample directed graph in 
Fig. 5, the composer would specify (at least) the operation "receivePurchaseOrder" 
corresponding to node 530 as a public interface. The composer may also provide a data mapping 
between an exposed operation and an internal service port type operation. For the sample 
directed graph in Fig. 5, having a public interface of "receivePurchaseOrder", the composer 
might specify (for example) a data mapping that converts data to a particular format required by 
this operation, such that an input parameter named "inputPurchaseOrder" adhering to a 
predefined type "purchaseOrder" would be available to the service upon invocation. Providing 
the data mapping may comprise identifying a canned transformation component, such as an 
integer-to-float transform; identifying a stylesheet which contains an appropriate transformation, 
such as an XSLT (Extensible Stylesheet Language Transformations) stylesheet; identifying 
customized transformation logic, which may for example convert one complex data type to 
another; and so forth. (Refer to the discussion of Fig. 1 1, below, for more information about 
declaring the interface to a web service intermediary and potential web service software 
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resources, and about providing transformation information.) The process of declaring the 
exposed port types (i.e. operations) results in the new service provider type for the aggregated 
composition. Thus, this new composition is itself a portlet proxy, or web service intermediary, 
that can be used as a building block in further compositions. 

5 The composer also provides a mapping for the deployment port type and for the system 

port type, if applicable, such that the resulting web service will be able to be used within a web 
service composition tool and will be able to be programmatically managed by the portal platform 
Pi as disclosed herein. This is preferably accomplished by prompting the composer (using a menu- 
y3 driven approach, for example) to identify operations and data mappings that will then be 
Ml represented in WSFL markup language <export> and <dataLink> elements, which enable 
::: providing a new interface and doing internal mapping for that interface. (Refer to section 4.5.3, 
□ "Data Links and Data Mapping", and section 4.6.4, "Exporting Operations", for more 
U information on the syntax and semantics of the <export> and <dataLink> elements.) 

In some cases, it may be desirable to generate the deployment and/or system port types 
1 5 (and similarly, the public interface of the portlet proxy) without reference to a particular target 
software resource. For example, suppose that run-time quality of service is an important factor 
in choosing a service provider for some service such as credit card processing. To provide a 
more generic interface which will programmatically adapt to one of several target service 
providers after a run-time service selection, according to the present invention, the composer may 
20 be asked to provide input for use in creating the WSDL document (see the description of Blocks 
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600 through 620; this process may be assisted by parsing class definitions and having the 
composer point to the right operations. The examples in Figs. 1 1 A and 1 IB show signatures that 
might exist for two candidate software resources for a credit card processing operation. The 
example in Fig. 1 1C shows a sample signature that might be designed as a superset which 
5 includes all parameters for both possible candidates. The manner in which a run-time mapping 
of input parameter values to the parameters required by the selected resource occurs is described 
below. 

fj In preferred embodiments, a WSFL "flow model" is used to persistently store the new 

kD service composition. Thus, the flow model of the newly-composed web service is created (Block 

a ft 

ill 720). This flow model is transmitted as a document accompanying the UDDI publish message 

"'%. s 

J2 for the new web service (Block 730), after which the new web service becomes automatically 
O available to service requesters (such as other business units of an organization or its business 
H* partners). A WSFL flow model is a markup language specification of the execution sequence of 
H the functionality provided by the web service which has been composed as a directed graph 
15 (where the directed graph was constructed during execution of Block 700). See section 8.4, "The 
Flow Models for Airline and Agent", in the WSFL specification for examples of flow models 
and their syntax. The WSFL specification provides a thorough description of the syntax 
requirements for flow models, and that discussion is not repeated herein. 



20 



The flow model used with the present invention may be programmatically constructed 
using the logic shown in Fig. 12, as will now be described. 
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The flow model construction process, wherein the directed graph created by the composer 
is converted to a WSFL flow model, is shown in Fig. 12 and begins at Block 1200 by locating 
the starting node of the graph. A WSFL activity element will be defined for each graph node, or 
operation, within the composition, as indicated by Block 1210, beginning from the located 
starting node. (Refer to the WSFL specification for a detailed description of the syntax of the 
elements created during the processing of Fig. 12.) Block 1220 then checks to see if this graph 
node has any edges which have not yet been processed. If this test has a positive result, then 
processing continues at Block 1240 which defines a control link for that edge. Control links will 
provide the flow between operations, using the WSFL run-time, and thus represent the edges of 
the composition graph. These links are then weighted with the transition conditions that specify 
the conditions under which that service interaction will execute (Block 1250). Data links are 
added (Block 1260) to the control links, as appropriate, to define the mapping of data between 
activity operations. Control then returns to Block 1220 to see if this node has any more edges to 
be processed. 

When the node's edges have all been processed, the test in Block 1220 has a negative 
result and control transfers to Block 1230, which checks to see if any more nodes exist in the 
graph which have not yet been processed. If this test has a positive result, control returns to 
Block 1210 to begin processing the next graph node. Otherwise, the public interface to this 
service is defined (Block 1270) as a collection of the declared operations and port types specified 
as part of the service provider type. Creation of the flow model document for this service is then 
complete. 
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Note that while the WSFL run-time provides the means for programmatically 
constructing a flow model diagram from a directed graph which represents a web service, the 
present invention extends the existing support by coupling this model with traditional portlet 
aggregation (that is, aggregating predefined port types, as extended herein to programmatic 
5 portlets) and injecting intelligent interface aggregation through external services. (This latter 
topic is described in more detail below with reference to "convert-lets".) 

Returning to the discussion of Fig. 7, after publishing the flow model to the registry, at 
n Block 740 the service selection process is performed for a newly-aggregated service. Service 
y5 selection is the act of binding a portlet (that is, the service provider type defined in the portlet 
Kf proxy's service definition) to an actual service provider (or providers) which provides software 
JS resources to fulfill that service process. The service selection operation may be performed 
Q according to the logic shown in Fig. 13, as will now be described. 

Preferably, the composer uses a toolkit such as WSTK to access a UDDI registry 
containing information about services that are available for aggregation. In Block 1300, an 

1 5 identification of the public or private registry to be queried is obtained. The composer may be 
prompted to enter this information; alternatively, it may be retrieved from a stored location such 
as a configuration file. The identification of one or more service taxonomies of interest is 
obtained (Block 1310), using similar techniques. The identified registry is then queried (Block 
1320) for entries matching the selected taxonomy information. In Block 1330, the tModels of 

20 the located entries are checked to select only the registered services which are enabled for and 
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which conform to the deployment (and, optionally, the system) port type(s) of the present 
invention. 

Optionally, message mapping is performed in Block 1340 to map messages and their 
associated data. The mapping provides one portion of the plug link information; the other 
portion is the locator information discussed below (see Block 1350). Message mapping is 
typically required, and is optional when there is a dual one-to-one correspondence between 
operations. Mapping may be defined using several techniques, of the type which has been 
described earlier (such as using XSLT stylesheets, referencing program logic, and so forth). Or, 
"convert-lets" may be used for performing the mapping; convert-lets are described below with 
reference to Fig. 15C. 

A service locator is defined (Block 1350), providing a mechanism to control how the web 
service intermediary will bind to a web service implementation. This may comprise creating a 
WSFL locator binding, using a <locator> element to identify a WSDL or WSFL service 
definition; or, it may comprise creating a UDDI-type binding on a <locator> element. 

A particular service provider can be selected by the composer as a static binding, for 
example based upon information obtained from UDDI yellow pages descriptions, for a static 
development-time binding of the web service intermediary to the service provider. Or, service 
provider selection can be specified as using a dynamic run-time binding, by using a dynamic 
locator. Therefore, Block 1360 checks to see if the binding will be static or dynamic. If it is to 
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be dynamic, the selection process will be deferred until run-time, and the composer preferably 
indicates one or more selection criteria (Block 1370) as UDDI service qualifiers to be used in the 
dynamic binding process. Examples of the semantics of such criteria include: select a service 
provider using the first hit returned from searching the registry; select a provider randomly; 

5 select a service provider that matches specific service qualifiers; etc. An example was previously 
discussed in terms of matching quality of service criteria for selecting a credit card processing 
service provider. The <locator> element for a dynamic binding preferably contains query syntax 
for use with the UDDI find operation, specified as the value of the "selectionPolicy" attribute. 

O (Refer to section 4.4.3, "Service Locators", of the WSFL specification for more information on 

Ml defining service locator elements.) 

pi At Block 1380, a plug link is generated for this web service. A WSFL "plug link" is a 

p markup language specification of mappings between the signature of the calling and called 

service provider operations (that is, between the portlet proxy's standard interface and the 
f: interface of the web service implementation). Section 4.7, "Plug Links", of the WSFL 
15 specification describes plug links in more detail. Fig. 14 illustrates a sample plug link 1400. In 

this example, the plug link specifies that if the "sendForm" message is received to invoke the 

"send" operation, it is to be mapped onto the "receiveForm" message to invoke the "receive" 

operation. 
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While plug links are known in the art, their use with portlet proxies is a novel aspect of 
the present invention. Note, however, that the data mapping support for plug links defined in the 
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WSFL specification provides a relatively restricted form of data mapping. A <map> element is 
provided, as shown at 1410, for a <dataLink> element of a flow model, which qualifies how to 
map one operation's message to another. The plug link defined by WSFL is limited to 
specifying a source message, a single target message, a source message attribute, and a single 
target message attribute. Thus, if one web service returned the markup document 1500 shown in 
Fig. 1 5 A, and needed to pass this information to an aggregated web service whose method 
signature was "submitName (Name: string)", the existing WSFL syntax allows specification of a 
mapping that would (for example) pass the value of the <firstName> element from document 
1500 as the input parameter to the submitName method. An example <map> element 1520 
which may be used within a plug link document to provide this mapping is shown in Fig. 1 5B. 
This is somewhat limiting in that operation attributes might not always map one-to-one, and 
transformations more complex than identifying an attribute for direct transfer might be 
necessary. For example, with reference to document 1500, it might be desirable to concatenate 
the values of the <firstName> and <lastName> elements for transfer to the next operation. 

The present invention, on the other hand, leverages the portal platform as an intelligent 
aggregator for programmatic portlets by extending the <map> element to include a specification 
of a <converter> attribute, as illustrated in Fig. 15C, (The <converter> attribute is referenced in 
the WSFL specification, section 4.5.3, "Data Links and Data Mapping". However, no 
information is provided therein as to how this attribute is used or implemented. Instead, the 
WSFL specification merely mentions that a converter attribute can specify a user-provided 
function for data mapping and conversion, and then goes on to state that the attribute is not yet 
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supported.) As shown therein, the attribute value is specified as a Uniform Resource Name 
("URN") identifying the portal platform. Since the portlet proxies of the present invention 
represent a standard interface for a web service aggregated in the portal platform (i.e. a web 
service intermediary), the portal platform can be used as a repository of portlet-to-portlet 

5 operation transformations. These transformations are referred to herein as "convert-lets", and 

may be referenced from the URN of a <converter> element. At ran-time, the portal platform will 
automatically select the appropriate convert-let from a portal transformation registry, such as the 
simplified transformation registry 1600 depicted in Fig. 16, and apply the transformation 

p between the web service operations. The transformations specified in this registry (see element 

l| 1610) may be arbitrarily complex, and may be implemented in a variety of ways. For example, 

y i 

9 { an XSLT stylesheet might be specified, or a piece of code implemented as a JavaBean or perhaps 
S even another portlet proxy (encapsulating a web service) could be specified for performing a 
O transformation. (As will be obvious to one of skill in the art, the sample registry 1600 is merely 
^ one example of an approach that may be used for identifying the convert-lets used for converting 
f$ data. For example, additional information might be contained in the registry, and formats other 
than the tabular format depicted in Fig. 1 6 might be used. In addition, the entries in this registry 
are not limited to one-to-one mappings: alternatively, a collection or set of "From" portlets 
and/or "To" portlets might be specified. Furthermore, rules or other criteria for identifying a 
"From" or "To" portlet might be specified, rather than explicitly identifying the portlets by 
20 name.) 



Optionally, if a transformation between two portlet proxy interfaces does not already 
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exist when those portlet proxies are used in modeling a new web service, as may be determined 
by consulting a portal platform's transformation registry, the service composer may be prompted 
to provide (or identify) an appropriate convert-let. 

Note that while the processing of Fig. 13 has been described as an in-line part of creating 
5 a new web service (by virtue of the logic of Fig. 7), this processing may also be performed for 

web services that have already been created and stored in the registry, to enable those services to 

be used according to the present invention by creating a web service intermediary for the existing 
H web service. In this case, the tModel validation of Block 1330 may be bypassed, as the 
m deployment and system tModels will typically have not been created for the registered web 
III service. The deployment port type is provided by mapping the appropriate operations of the web 
j£ service, as described above with reference to Fig. 12. (The composer may specify new 
Pi operations if the existing web service does not provide the necessary operations. For example, if 
M» the web service does not include an operation to retrieve icons which will represent the service 
p on the palette of the composition tool, the composer may add these operations.) If the underlying 
1 5 software resources provide auditing information, the composer may specify a mapping between 

these operations and the system port type. A WSFL plug link is then generated to represent this 

mapping and data transfer, as discussed earlier. 

Returning again to Fig. 7, once the service provider selection process of Block 740 is 
complete, a WSFL "global model" for the service bindings is created (Block 750), A WSFL 
20 global model is a markup language specification of links between endpoints of web service 
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interfaces, with each link corresponding to one web service's interaction with another web 
service's interface. WSFL plug links are used in the global model to describe the interaction 
between the portlet proxy and the selected service provider (or, alternatively, a candidate service 
provider). Section 4.8, "Global Model", of the WSFL specification describes global models in 
more detail. 

The global model (or models, if there is more than one candidate service provider) are 
published to the registry (Block 760), in addition to publishing the flow model at Block 720, in 
order to specify binding information for use with the newly-created service composition 
represented by the flow model. Note that reuse of the flow model for more than one global 
model allows other service providers to be plug-linked into the service interaction flow through 
the portlet proxy by substituting a different global model. Additionally, publishing the 
composition's flow model in the registry allows for the flow model to be retrieved and 
decomposed so that elements can be added, removed, or changed (e.g. in a web service 
composition tool such as that illustrated by Fig. 5) as necessary to create a new web service. (It 
may be desirable in some cases to prevent this type of decomposition and modification, for 
example when privacy or security is a concern. For such cases, a capability for privately 
publishing the flow model may be provided.) 

Turning now to Fig. 17, the automated management of web services which is facilitated 
by the system port type of the present invention will be described in more detail The system 
port type is used at run-time, and enables communication of life cycle events which are necessary 
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for a portlet proxy to operate within a portal platform. These life cycle events include operations 
such as "spawn" for creating a new instance and "terminate" for terminating an instance. 
Additional life cycle events include "call", for executing an instance; "enquire", for querying the 
status of an instance; "suspend", for suspending an instance; and "resume", for resuming an 
5 instance. The WSFL specification describes these six life cycle events in more detail, and 

existing WSFL support is preferably used for implementing these six life cycle events. (The 
portal platform calls methods of visual portlets of the prior art for carrying out such events, and 
the portal platform preferably calls a programmatic portlet according to the present invention in 
f5 the same manner.) The system port type also allows communication back to the portal platform 
tH for performing functions such as reporting of events for a log, reporting information for use in 
p I billing for services, reporting of quality of service data, reporting various types of run-time 
jjj execution errors or other operational events, etc. These reporting-type functions may be referred 

ri to as an "auditing" interface of a portlet proxy. In order for this auditing information to be sent 

■-ft 

H to the portal platform, the portlet proxy must have a way to initiate communications with the 
| J> platform. This type of 2-way communication between a portal platform and a portlet is not 
available in the prior art. According to the present invention, this communication is made 
possible by registering the portal platform itself as a web service which is then accessible from a 
registry. (This registration of the portal platform may occur at any time before the platform 
begins interacting with programmatic portlets as disclosed herein, and thus this registration has 
20 been omitted from Fig. 17.) 



When the portal platform deploys a portlet proxy which includes the system port type, the 
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logic shown in Fig. 17 may be used to enable communication of data using the portlet proxy's 
auditing interface. Beginning in Block 1700, the portal platform searches the registry for the 
portlet proxy it wants to communicate with. Preferably, this search looks for a web service 
having a tModel which specifies the system interface (and optionally the deployment interface) 
5 disclosed herein. Upon finding an appropriate web service, the portal platform binds to the 
system port type of that web service (Block 1710). The portal platform can now initiate 
communications with the portlet proxy. At Block 1720, the (previously-registered) portal 
platform programmatically provides its URN to the portlet proxy (for example, by invoking a 
H "setURN" method of the portlet proxy). The portlet proxy then uses this URN to look up the 
Lfl portal platform's interface (from the portal platform's information in the registry), as shown in 
y\ Block 1730. The portlet proxy then uses the portal platform's registered information to bind to 
Jj: its system port type (Block 1740). At this point, the 2-way communication is established and the 
ri portlet proxy can now initiate communications with the portal platform (by programmatically 
H invoking the appropriate operations of the platform). Block 1750 indicates that the portal 
li platform may call life cycle operations of the portlet proxy, such as the "enquire" operation, and 
Block 1760 indicates that the portlet proxy may also call auditing operations of the portal 
platform, such as a "logEvent" or "reportUsage" operation which was previously described with 
reference to Fig. 4B. 

Fig. 18 illustrates an overview of the components which have been described herein. A 
20 portal platform 1800 includes (or accesses) a transformation registry 1805, which stores convert- 
lets (i.e. mappings between programmatic portlets). A first programmatic portlet 1820, which 
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includes a deployment interface 1822, system interface 1824, and web service functional 
interface 1826, needs to supply information to a second programmatic portlet 1860 which 
includes similar interfaces 1862, 1864, 1866. Presumably, portlet 1820 obtains this data from 
execution of a first web service 1840, where plug link 1830 provides for programmatic 
5 interactions between portlet 1 820 and web service 1840, and portlet 1 860 will pass this data to a 
second web service 1880, using plug link 1870 to programmatically interact with web service 
1 880. A transformation is required in this example before the data can be passed between the 
programmatic portlets. This transformation will be performed by convert-let 1850, which has 
f i been programmatically retrieved from the transformation registry 1805, as shown at 1 852. The 
1 ; Q WSFL run-time 1810 coordinates and manages these interactions through execution of the flow 
m models and global models which have been created to represent the programmatic portlets 1 820, 

1860 and their interfaces to the web service implementations 1840, 1880, rendering the WSFL 
ri markup by flowing the defined work flow and calling the appropriate activities through the 
H defined mappings (or the dynamically-determined mappings specified by convert-lets). 

15 As has been demonstrated, the present invention provides advantageous techniques for 

aggregating, deploying, and managing web services. A dual aggregation model was disclosed, 
whereby a WSFL run-time provided for modeling aggregation of services was combined with 
traditional portal aggregation services available through a portal platform (and extended as 
disclosed herein to address programmatic portlets), thereby providing the "glue" for using 

20 programmatic portlets in a portal platform to enable aggregating programmatic portlets in a 
portal in real-time. The disclosed techniques enable this to occur programmatically, without 
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requiring manual intervention. Programmatic portlets are modeled as web service intermediaries 
to either local software resources or remote resources, and/or other portlets. Web service models 
are expressed and published as WSFL flow models, and service providers are linked using 
WSFL global model expressions. Open standards are leveraged for business process modeling 

5 and integration, defining significant advances in the web services field. Note that while 
particular standards (such as WSFL) have been referenced when describing preferred 
embodiments, this is for purposes of illustrating the inventive concepts of the present invention. 
Alternative means for providing the analogous functionality may be used without deviating from 

H the scope of the present invention. 

yi 

iO As will be appreciated by one of skill in the art, embodiments of the present invention 

Jri may be provided as methods, systems, or computer program products. Accordingly, the present 
pi invention may take the form of an entirely hardware embodiment, an entirely software 

embodiment, or an embodiment combining software and hardware aspects. Furthermore, the 
O present invention may take the form of a computer program product which is embodied on one or 
1 5 more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, 

optical storage, and so forth) having computer-usable program code embodied therein. 

The present invention has been described with reference to flow diagrams and/or block 
diagrams of methods, apparatus (systems), and computer program products according to 
embodiments of the invention. It will be understood that each flow and/or block of the flow 
20 diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams 
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and/or block diagrams, can be implemented by computer program instructions. These computer 
program instructions may be provided to a processor of a general purpose computer, special 
purpose computer, embedded processor or other programmable data processing apparatus to 
produce a machine, such that the instructions, which execute via the processor of the computer or 
other programmable data processing apparatus, create means for implementing the functions 
specified in the flow diagram flow or flows and/or block diagram block or blocks. 

These computer program instructions may also be stored in a computer-readable memory 
that can direct a computer or other programmable data processing apparatus to function in a 
particular manner, such that the instructions stored in the computer-readable memory produce an 
article of manufacture including instruction means which implement the function specified in the 
flow diagram flow or flows and/or block diagram block or blocks. 

The computer program instructions may also be loaded onto a computer or other 
programmable data processing apparatus to cause a series of operational steps to be performed on 
the computer or other programmable apparatus to produce a computer implemented process such 
that the instructions which execute on the computer or other programmable apparatus provide 
steps for implementing the functions specified in the flow diagram flow or flows and/or block 
diagram block or blocks. 



While the preferred embodiments of the present invention have been described, additional 
variations and modifications in those embodiments may occur to those skilled in the art once 
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they learn of the basic inventive concepts. Therefore, it is intended that the appended claims 
shall be construed to include both the preferred embodiment and all such variations and 
modifications as fall within the spirit and scope of the invention. 
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